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          Stateless Source Address Mapping for ICMPv6 Packets

Abstract

   A stateless IPv4/IPv6 translator may receive ICMPv6 packets
   containing non-IPv4-translatable addresses as the source.  These
   packets should be passed across the translator as ICMP packets
   directed to the IPv4 destination.  This document presents
   recommendations for source address translation in ICMPv6 headers to
   handle such cases.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6791.
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Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
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1.  Introduction

   Section 5.3 of "IP/ICMP Translation Algorithm" [RFC6145] states that
   "the IPv6 addresses in the IPv6 header may not be IPv4-translatable
   addresses and there will be no corresponding IPv4 addresses
   representing this IPv6 address.  In this case, the translator can do
   stateful translation.  A mechanism by which the translator can
   instead do stateless translation of this address is left for future
   work."  This document, "Stateless Source Address Mapping for ICMPv6
   Packets", provides recommendations for this case.

   For the purposes of this document, the term "IPv4-translatable IPv6
   address" is as defined in Section 2.2 of [RFC6052].
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2.  Notational Conventions

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

3.  Problem Statement and Considerations

   When a stateless IPv4/IPv6 translator receives an ICMPv6 message
   [RFC4443] (for example, "Packet Too Big") sourced from a non-IPv4-
   translatable IPv6 address and bound for an IPv4-translatable IPv6
   address, the translator needs to pick a source address with which to
   generate an ICMP message.  For the reasons discussed below, this
   choice is problematic.

3.1.  Considerations

   The source address used SHOULD NOT cause the ICMP packet to be
   discarded.  It SHOULD NOT be drawn from [RFC1918] or [RFC6598]
   address space, because that address space is likely to be subject to
   unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering.

   IPv4/IPv6 translation is intended for use in contexts where IPv4
   addresses may not be readily available.  Therefore, it is not
   considered appropriate to assign IPv4-translatable IPv6 addresses for
   all internal points in the IPv6 network that may originate ICMPv6
   messages.

   Another consideration for source selection is that it should be
   possible for the IPv4 recipients of the ICMP message to be able to
   distinguish between different IPv6 network origination of ICMPv6
   messages (for example, to support a traceroute diagnostic utility
   that provides some limited network-level visibility across the IPv4/
   IPv6 translator).  This consideration implies that an IPv4/IPv6
   translator needs to have a pool of IPv4 addresses for mapping the
   source address of ICMPv6 packets generated from different origins, or
   to include the IPv6 source address information for mapping the source
   address by others means.  Currently, the TRACEROUTE and MTR [MTR] are
   the only consumers of translated ICMPv6 messages that care about the
   ICMPv6 source address.

3.2.  Recommendations

   The recommended approach to source selection is to use a single (or
   small pool of) public IPv4 address as the source address of the
   translated ICMP message and leverage the ICMP extension [RFC5837] to
   include the IPv6 address as an Interface IP Address Sub-Object.




Li, et al.                   Standards Track                    [Page 3]

RFC 6791            Source Address Mapping for ICMPv6      November 2012


4.  ICMP Extension

   In the case of either a single public IPv4 address (the IPv4
   interface address or loopback address of the translator) or a pool of
   public IPv4 addresses, the translator SHOULD implement the ICMP
   extension defined by [RFC5837].  The ICMP message SHOULD include the
   Interface IP Address Sub-Object and specify the source IPv6 addresses
   of the original ICMPv6.  When an enhanced traceroute application is
   used, it can derive the real IPv6 source addresses that generated the
   ICMPv6 messages.  Therefore, it would be able improve on visibility
   towards the origin rather than simply blackholing at or beyond the
   translator.  In the future, a new ICMP extension whose presence
   indicates that the packet has been translated and that the source
   address belongs to the translator, not the originating node, can also
   be considered.

5.  Stateless Address Mapping Algorithm

   If a pool of public IPv4 addresses is configured on the translator,
   it is RECOMMENDED to randomly select the IPv4 source address from the
   pool.  Random selection reduces the probability that two ICMP
   messages elicited by the same TRACEROUTE might specify the same
   source address and, therefore, erroneously present the appearance of
   a routing loop.

   [RFC5837] extensions and an enhanced traceroute application, if used,
   will reveal the IPv6 source addresses that generated the original
   ICMPv6 messages.

6.  Security Considerations

   This document recommends the generation of IPv4 ICMP messages from
   IPv6 ICMP messages.  These messages would otherwise have been
   discarded.  New considerations are not expected to result from this
   change.  As with a number of ICMP messages, a spoofed source address
   may result in replies arriving at hosts that did not expect them
   using the facility of the translator.
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